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(57) A cable television communication system net- 
work (10) comprising a remote hub (14) which is in com- 
munication with a plurality of head ends/central office 
(18) via a fibre optic interface, a plurality of user termi- 
nals (16) associated with each head end via a hybrid 
fibre coax interface and a plurality of interactive and 
broadcast video information providers ( VIPs) ( 1 2) which 
are in communication with the remote hub (14). The 
remote hub includes means for formatting broadcast 
signals received from selected VIPs of the broadcast 
VIPs (12) for direct transmission to the head erxl/user 
terminal interfaces such that the user terminals (16) 
receive said formatted broadcast signals without refor- 
matting by said headends. means for selectively con- 
trolling distritxjtion of communication signals between 
said interactive VIPs and said headends (18). means for 
tracking usage of VIP services by said user terminals for 
at least billing purposes. Each said headend (18) 
means for facilitating interactive VIP communications 
between its associated user terminals 16) and said 
VIPs (12). 
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(54) Distributed system architecture for digital broadcast and interactive services 



(57) A cable television communication system net- 
work (10) comprising a remote hub (14) which is in com- 
munication with a plurality of head ends/central office 
(18) via a fibre optic interface, a plurality of user termi- 
nals (16) associated with each head end via a hybrid 
fibre coax interface and a plurality of interactive and 
broadcast video information providers (VIPs) (12) which 
are in comnrtunication with the remote hub (14). The 
remote hub includes means for formatting broadcast 
signals received from selected VIPs of the broadcast 
VIPs (12) for direct transmission to the head end/user 



terminal interfaces such that the user terminals (16) 
receive said formatted broadcast signals without refor- 
matting by said headends, means for selectively con- 
trolling distribution of communication signals between 
said interactive VIPs and said headends (18). means for 
tracking usage of VIP services by said user terminals for 
at least billing purposes. Each said headend (18) 
means for facilitating interactive VIP communications 
between its associated user terminals 16) and said 
VIPs (12). 
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Description 

This invention relates generally to cable television communication systems. More particularly, the invention relates 
to a cable television communication network architecture that allows distributed delivery of broadcast and interactive 
5 digital services over a hybrid fiber-coax metropolitan area network to consumer residences. 

The tremendous growth in the use of computer networks and electronic databases over the past decade has 
resulted in the accumulation of a wealth of electronic information. In order to remain competitive, businesses and indi- 
viduals increasingly have sought access to this electronic information via on-line services and databases. Although the 
diversity of electronic interactive services is expected to increase, the means to transmit the information to businesses 
10 and homes has remained rather limited. Most of the limitations involve the physical infrastructure that existed in the past 
and to some extent still exists. Existing upgraded coaxial CATV networks and copper pair telephone networks are gen- 
erally unable to handle the tremendous amounts of electronic data that must be transmitted, should the availability of 
interactive services become universal. 

One solution to overcome the limitations introduced by the physical networks is to replace the current CATV and 
IS telephone networks with fiber optic networks, which are capable of can^ying much more information. However, total 
replacement of an established network with fiber optic components is cost prohibitive. Although the use and diversity of 
interactive services is expected to grow in the future, the extent of the growth is unknown. Additionally, there are many 
types of services that have not yet been envisioned but will require support from any network that is established. 

Accordingly, there exists a need for an information transport infrastructure that is capable of efficiently and optimally 
20 transporting digital and analog communications between information service providers arxJ service requestors. This 
infrastructure must be capable of supporting existing services as well as expanding to support future services. 

The network architecture of the present Invention allows distributed delivery of broadcast and interactive digital 
services over a hybrid fiber-coax metropolitan area network to service requestors. The network provides an information 
transport infrastructure that increase the capability of hybrid ftoer-coax transmission systems. The network includes at 
25 least one remote/local hub that communicates with a plurality of video information providers (VIPs) and a plurality of 
headends/central offices. Each headend communicates with a plurality of settop terminals. The hub includes a back- 
bone subnetwork which provides the physical medium for components within the hub to communicate with each other, 
and for entities located outside the hub. such as the VIPs and the headends. to communicate with, and through, the 
hub. The hub processes broadcast digital information services from the VIP and distributes the services directly to the 
30 plurality settop terminals. The headends facilitate interactive communications between the VIPs and the settop termi- 
nals served by that particular headend. 

The network architecture permits two-way transparent (protocol stack independence, layer 3-7) data transport 
sen/ice between the VIPs and the video information users (VIUs) at the STTs. Through frequency division multiplexing, 
the network architecture facilitates analog signal distribution. Accordingly, the network is compatible with distritxjtion 
35 systems which provide analog services. 

Accordingly, it is an object of the present invention to provide network architecture for the distributed delivery of 
broadcast and interactive digital services. 

It is a further object of the invention to provide a network architecture which is compatible with distribution systems 
capable of providing analog services. 
40 It is a further object of the invention to provide a network architecture that provides for equitable access by multiple 
video information providers. 

It is a further object of the invention to provide a network architecture that does not impose any protocol stack 
requirements on the communications from the video information providers. 

It is a further object of the invention to provide a modular and scalable network architecture which allows for incre- 
45 mental agreement deployment by the network provider. 

It is a further object of the invention to provide a network architecture that is easily tailored to and is independent of 
the type of network provider (a cable operator or a regional phone company). 

Other objects and advantages of the system will become apparent to those skilled in the art after reading the 
detailed description of a presently preferred embodiment. 

50 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram of an end-to-end cable television communication network embodying the present 
invention: ' 
55 Figure 2 is a block diagram of the remote/local hub of the present invention; 

Figure 3 is a block diagram of a headend/central office of the present invention; 

Figure 4 is a block diagram of the cable television distribution network of the present invention; 

Rgure 5 is a block diagram of a settop terminal of the present invention; 

Figure 6 is a prior art layered protocol stack; 
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Figure 7 is a prior art link level frame format used in conjunction with the protocol stack of Figure 6: 

Figure 8 is the ISO-OSI based protocol stack during protocol syntax processor upgrade in accordance with the 

present invention: 

Figure 9 is an example of a frame format of the link layer protocol: 

Figure 10 is a flow diagram of the migration from an old protocol syntax processor to a new protocol syntax proc- 
essor: 

Figure 1 1 is the frame format of Figure 9 including the test frame structure: 

Figure 12 is a flow diagram of the testing procedure of a new protocol syntax processor: 

Figure 13 is an example of values transmitted in the test frame format for a field check: 

Figure 14 is a flow diagram of the recovery procedure of the slave node of the present invention; 

Figure 15 Is a time division multiple access frame utilized in the preferred embodiment of the hybrid MAC: 

Figure 1 6 is a block diagram of the space, frequency and time domains of the hybrid MAC: 

Figures 1 7A and 1 7A-1 are a flow diagram of the (RSR/ASA) time division multiple access component of the hybrid 

MAC: 

Figure 178 is a flow diagram of the multi-rate dynamic time diversion multiple access component of the hybrid 
MAC: 

Figure 18 is the preferred DLL packet sublayer of the present invention: and 

Figure 19 is the preferred MPEG2 based DLL message sublayer of the present invention. 
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AAL5 


ATM Adaption Level 5 




AC 


Addressable Controller 




ASEM 


Access Subnetwork Element Manager 


ATM 


Asynchronous Transfer Mode 




APP 


Adaptive Protocol Processor 




CLP 


Cell Loss Priority (ATM) 




CRC 


Cyclic Redundancy Code 




DLL 


Data Link Layer 




DSA 


Dynamic Slot Allocation 




DTE 


Data Terminal Equipment 




ECM 


Entitlement Control Messages 




EIA 


Electronics International Association 


EMM 


Entitlement Management Messages 




FDM 


Frequency Division Multiplexing 




FTTN 


Fiber To The Node 




GFC 


Generic Flow Control (ATM) 




HEC 


Head Error Check (ATM) 




HFC 


' Hybrid Fiber Coax 




IBTM 


In*band Transport Multiplex 




IP 


Internet Protocol 




IR 


Infrared 




IPPV 


Impulse Pay Per View 




ITEM 


Integrated Transport Encryption 


Multiplexer 


LAN 


Local Area Network 




LLC 


Logical Link Control 




LIG 


Level One Gateway (regulated by 


the FCC) 


L2G 


Level Two Gateway (unregulated by the FCC) 
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MAC Medium Access Control 

MPEG2 Motion Picture Expert Group 2 

MPTS Multi Program Transport Multiplex (MPEG2) 

NVRAM Non-Volatile Random Access Memory 

PES Packetized Elementary Stream 

PSI Program Specific Information 

OAM&P Operation Administration Maintenance 

Provisioning 

OBTM Out of band transport multiplex 

OSI Open Systems Interconnection 

OSS Operation Support System 

PAT Program Association Table {MPEG2) 

PGR Program Clock Reference (MPEG2) 

PCS Personal Communication Services 

PDU Protocol Data Unit 
PID Packet Identifier 

PMT Program Map Table 

POP Plain Old Polling 

POTS Plain Old Telephony Service 

PPV Pay Per View 

PSI Program Specific Information 

PSP Protocol Syntcuc Processor 

PT Payload Type 

QAM Quadrature Amplitude Modulation 

QPSK Quadrature Phase Shift Keying 

RSR Random Slot Reservation 

SDU Service Data Unit 

SPTM Single Program Transport Multiplex (MPEG2) 
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10 



15 



STT Settop Terminal 

VCC Virtual Channel Connection (ATM) 

VCI Virtual Channel Identifier (ATM) 

VDT Video Dial Tone 

VIP Video Information Provider (information owner) 

VPI Virtual Path Identifier (ATM) 



WAN 



Wide Area Network 



A CATV communication network 10 embodying the present invention is shown in Figure 1. The com'municatioi 
20 network 10 generally comprises a remote/local hub 14 which communicates with a plurality of headends/central offic* 
18. each of which in turn communicate with a plurality of settop terminals (STTs) 16. The STTs 16 are the interfac 
between the television of a video Information user (VIU) and the communication network 10. The remote/local hub 1* 
may be physically located remote from the headends 18 or. alternatively, may be located at the site of any one of th* 
headends 18. The communication network 10 interfaces with a plurality of video information providers (VIPs) 12 whic! 
25 provide compressed digital video and services. Through the remote hub 14 and the headends 18. the communicatloi 
network 10 provides two-way transparent (protocol stack independence, layer 3-7) data transport service between th. 
VIPs 12 and the video information users at the STTs 16. The hdb 14 provides broadcast information services from th* 
VIPs 12 to ail STTs 16 on the network 10. The headends 18 facilitate interactive communications between the VIPs 1: 
and the STTs 16 that are sen/ed by that particular headend 18. In the preferred embodiment of the invention, commu 
30 nications between the VIPs 12. the remote/local hub 14 and the headend/central offices 18 are transmitted over a f ib€ 
optic medium. 

To provide the bi-directional communication flow over the network 10. frequency spectrum of the physical mediur 
from the headend 18 to the STTs 16 is divided into a downstream signal path originating at the headend 18 and a^ 
upstream signal path originating at the STTs 16. The bandwidth of the physical medium in the preferred embodimer 

35 extends up to 1 GHz. The downstream bandwidth typically employs frequencies above 50 MHZ. and the upstream fr€ 
quendes below 50 MHZ. The downstream and upstream bandwidths are further divided into 6 MHZ channels. In th 
present invention, a portion of the 6 MHZ channels are allocated for analog communications and the remainder for die 
ital communications. Accordingly, analog and digital communications may be frequency division multiplexed (RDM) ov€ 
the separate channels and transported over the same physical medium. Analog CATV communication systems are we 

40 known in the art. such as the system disclosed in U.S. Patent No. 4.533.948. (to McNamara et al.) and in U.S. Pater 
No. 4.245.245. (to Matsomoto et aL), which are incorporated by reference as if fully set forth. 

Referring to Rgure 2. a remote/local hub 14 made in accordance with the teachings of the present invention i 
shown. The hub 14 Includes a level 1 gateway (LiG) 20. an access subnetwork element manager (ASEM) 22. a 
addressable controller 24. a billing system 26 (co-located or remotely located), an operations support system (OSS) 2 

45 (co-located or remotely located), an integrated transport encryption multiplexer (ITEM) 30. a 64 quadrature amplitud 
modulation (QAM) modulator 32. an RF upconverter 34. a quadrature phase shift keying (QPSK) modulator(s) 3 
(optional) and an asynchronous transfer mode (ATM) services multiplexer 38. A backbone subnetwork 40 provides th 
physical medium and the optical to electrical interface for components within the hub 14 to communicate with eac 
other and for outside entities (such as the VIPs 12 and STTs 16) to communicate with, and through, the hub 14. Con 

so munications between the hub 14 and the headend 18 elements are conducted via Internet protocol, asynchronoi 
transfer mode (IP/ATM) signaling in WAN connectivity and IP/Ethernet in LAN connectivity. There may be more the 
one of each of these components depending upon system capacities (i.e. desired number of channels for the ITEM 3 
number of subscribers for the AC24 etc.). 

The specific components which comprise the network architecture of the present invention will now be present€ 

55 in detail. The video information provider (VIP) 12 consists of a level two gateway (L2G) and associated servers. TV 
L2G acts as an interface between the VIP 12 and the network 10. The VIPs 12 are the source of live, archival broadca 
or interactive service content, (comprising electronic encyclopedias, electronic catalogs, downloadable application 
movies, etc.). communications with the network 10. and service menus. The L2G communicates with the LiG 20 
manage the establishment and termination of service/session connections between the VIUs and the VIPs 12. The L2 



6 



EP 0 730 383 A2 



menu presentation and selection processing to and from the VIUs. performs VIU authentication and for- 
^'^^/h h no information for VIP 12 provided services to the billing system 26. 

wards Dim g „ iG) 20 provides overall management of network 1 0 in support of service delivery from a VIP 

wnlLTThe L1G 20 pertorms the following functions: 1) management of VIP-VIU interactive sessions through com- 
,o a ViU(s). m authentication and collection of billing information relating to network 10 support of 

Tp^'SlTg 20 provided services for fon«arding to the billing system 26; 3) interactive menu presentation whidi is 
)^^onsive to the service selected: and 4) database management of VIU profiles for digital broadcast and interactn^e 

'^'^S access subnetwork element manager (ASEM) 22 acts as an agent to (i.e. is controlled by) the LJG 2° a-xJ/or 
OSS (de^en^^g on the functions to be performed by the ASEM 22). At the direction of the LIG 2a the ASEf^ 22 pro- 
SJes mSIgement of headend 1 8 components (shown in Rgure 3). much in the same manner as the LIG 20 oversees 
manioement of resources on the backbone subnetwork 40 (via a designated backbone network manager not shown). 

ASEM determine which item and NC can accommodate a new connection (based on already ut zed resources 
ITthin each) and the LIG 20. The ASEM 22 conveys parameters such as ATM virtual path identrf.er (VPI) and v.r ual 
^a^nel id^ifier (VCl) values for session signaling and session content to the ITEMs 30 50 and the network corrtrd- 
^rs 62 The ASEM 22 also conveys associated transmission rates for the downstream ATM VPIA/CI and signa''"g '^tes 
or upstream as conveyed to it by the LIG 20 (these values are originated by the VIP 12/l^G). The ASEM 22 forwards 
appropriate scheduling parameters to the addressable controller 24 for enayption of pay-per-view (PP^^^ '"Pu'se- 
oav-oer-view (IPPV) services by the ITEMs 50. In the preferred embodiment of the invention, the ASEM 22 oversees 
OAM&P (Operation Administration Maintenance and Provisioning) functions through the backbone subnetwork 66 and 
interfaces with the OSS center 28 to convey status or any OAM&P information of elements within the hubs (Mux/Mods. 

Demod/Muxes, etc.)totheOSS28. w>^^„^<.«=i„h 
The addressable controller 24 manages the secure delivery of broadcast, pay-per-view and non-video-on-demand 
(staggercast) services, including VIU authorization for those services and program scheduling by controlling the 
encn^on subsystem. Access control and encryption parameters are fo™«rded to network elements which perform 
dowr^tream and upstream encryption and decryption. In the preferred embodiment of ttie invention ^^o^n^^f^;" 
encryption is implemented in the ITEMs 30. 50 and downstream deayption is implemented in networK modules 70. 
which are part of each STT 16. Upstream encryption is implemented in the network module 70 f •^.."'fj^a") f/^yP" 
tion is performed by a networi< controller 62. For interactive service communications, which are faalitated at the head- 
ends 18 the addressable controller 24 pr^rovisions the ITEMs SO and the network modules 70 with the appropriate 
encryption/deayption parameters. For broadcast service communications, which are facilitated by the hub 14 the 
addrSsable controller 24 fonwards similar parameters to the ITEM 30 based on scheduling information fon<i«rded by 

"TrSfrnMSt^n^rt^encryption multiplexer (ITEM) 30 provides secure delivery of broadest digital services 
information to thfviUs^an in-lSnd transport multiplex (IBTM). The ITEM 30 originates the IBTM including video, 
luS o dal^ by performing ATM to MPEG2 reassembly and readaption (AAL5) of single pK,gram transport rnultip^ 
(SPTM) This includes ATM to MPEG2 reassembly of audio-visual content. ATM to AAL5-serv.ce data unrts (SOU) reas- 
sembly of non-MPEG2 data and removing jitter and adjusting program clock reference (PGR) timing for audio visual 
content. The ITEM 30 creates an aggregate MPEG2 multiplex from any input SPTM to any output mult-program trans- 
port multiplex (MPTM). In doing so. the ITEM 30 unquely reassigns packet identifier (PID) values. !fj" ^ij;^^^^^^ 
stream (program specific information (PSI) including a program association table (PAT) and a program (PMT) taWe 
and sel^K/ely encrypts SPTMS as instructed by the ASEM22. The ITEM 30 updates the aggregate sfream PGR and 
inserts entitlement control messages (ECMs). It also performs similar operations when -^'JP'^'^Q ^-^f ^^^^^^ 
and addressable controller 24 messages (including entitlement management message (EMMs)) on the out-of-band 
« transport multiplex (OBTM) which is then forwarded to the QPSK modulator 36. 

The ITEM 30 provides a transport interface for digital broadcast communications between the VIPs 1 2 and the b 1 1 
16 via the backbone subnetwork 40 (or through direct interfaces H co-'o^ted). Broadcast 'f 
signaling originated by the VIPs 12 is forwarded to the STT 16 via the ITEM 30. More specifically, the ITEM 30 accep^ 
an ATM stream via an ATM/SONET interface (with sustained cell rate version of AAL5) ^"^i'^'^^*^ 
so for MPEG2 packet reassembly based on the value of the VCl which is conveyed by the ASEM 22 to the TEM 30 during 
connection establishment. This is achievable since the virtual connection between the VIP 1 2 and the VIU is maintamed 
end-to-end The resulting MPEG2 transport multiplex (consisting of multiple audiovisual information streams protocol- 
independent, from an ITEM 30 standpoint, information streams carried as AALS-SDUs (such as stockquotes) is output 



15 



20 



25 



30 



35 



40 



to the 64 QAM modulator 32. ^ .^^^^ , ^ , ^^^..wo o..r 

in order to ensure secure delivery of a given broadcast audiovisual sen/ice. the ITEM 30 ^^'^^^'^^^^ 
suant to the addressable controller 24 configuration, a given set of MPEG2 P^<;»9L^^"^^7^"^J'^ 
port stream. Access control and encryption related information is forvvarded to ITEM 30 from the ^^^^^^^^le c^^^^^ 
24. The ITEM 30 incorporates this information within the MPEG2 transport stream per MPEG2 
and encrypts as instructed by the addressable controller 24. Each output of the ITEM 30 .s fon««rded to a single 64 
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n/.M modulator 32 whose output is converted to the selected downstream channel by an RF upconverter 34 arxl then 
co^l^^S by an RF^SS^iner 35 for downstrearn t«^^^^^ Each ITEM 30 Keeps tracK of the resources recu.red.or 

' '''-^^QArmodulator 32 accepts the downstream IBTM output of -ITEM 30. applies fon«a«l error correction and 64 

OBTM it "J"^ 'S°Z^^,^^^,^^eS<^LZ^^ ca,rl» freguenaes (41 .0 ■ 47.0) 

switches or remotely via the Et^^^^^^^ 

as though all components reside on tf«e • support of the network 10. The billing system 

tions of both of these components is well known to those skilled m art _ 

Referring to Rgure 3. a headend 18 made .n ^^^'^^^I'^f:^^^'^^^^^^ digital broadcast 

headend 18 facilitates digital interactive communications between ^'^^fj.^^^f™^^^^^ headend 18 by combin- 

communica«ons which were processed by the hub J";^';- -3;^"^^^^^^ ri,uired. 

ers(notsh<«vn)^Ac«rding.y no^^^^^^^ 5, ^„ 54. a 

rrr^sre^r^Erc^^^^^ 
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35 



"^'l^tlTEMSOprov^essecureder^ryofinterac^vedig^se^^^^ 

ally, it can be configured to provide broadest ^^^^'^^^^f, tj'jf "^'^^ItX^ reassembly and 

^originates the IBTM including video, audio. '^^-^J,^^^^^^^^^ to AALS-SDUs 

re-adaption (AAL5) of SPTM-s. This includes ATM to ^^P^^^^;,^^fi^'r"^ -^^^ and adjusting PGR timing. The 

« reassembly of session signaling or ^^/""^ from any input 

ITEM 50 creates an aggregate MPEG2 '"""'f f • ^'^J^J^? Si unk»"ely reassigns PlLrvalues. 
SPTM to any output MPTM. As is performed by the ITEM 30 1" *l.hub 14.Jhe '^^^^^^ ^^ ^^ream PGR and 

- in support Of QAM mux/m<!d 52 is input to the RF upconverter 54, 

forward error correction and gO or The addressable controller 24. (and optional application down- 

loads ro^^l 0^0:^0^^^^ art sent from the ITEM 50 to the QPSK mul«p.exer modulator 
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S8 The QPSK mux/mod 58 accepts the output of the ITEM 50 and multiplexes MAC information as in the in-band case. 
?he QPSK mu^.^ Salso pr^ides forwa«l error correction and QPSK modulation for the OBTM transm.ss.on. The 
output is input to the RF combiner 59 for downstream transmission. 

The primary function of the network controller 62 is to administer medium access ('^'^C) 
neiwork module 70 interfacing to the network 10. MAC is a sublayer of the data link layer which f 
mission Of data from various network modules 70 to the headend 18 based on fair access and 
ance. The network controller 62 determines the MAC operating parameters based on th**® by the AS^^^ 

includlna but not exclusive to: 1) fiber to the node (FTTN) size: 2) upstream spectrum allocation (8-12MHz. 8-15MHz). 
3) Jansmlssion rati: and 4) QPSK mux/mod 58 and QPSK demux/mod 60 configuration 0 e^onn^cu^ 

to the network controller 62 which will allow the network controller 62 to route information such as acknowledgments (to 
upstream transmitted packets), through the appropriate QPSK mux/mod 58 or QAM mux/mod 52^ 

The network controller 62 also administers the type of upstream access that will be required: 1 plain old poll ng 
(POP)- 2) default assigned TDMA; and 3) dynamically assigned TDMA carriers (frequency and time slot assignmen s). 
The resources allocated by the network controller 62 for connection-oriented MAC service requests are based upon he 
I^sirS session bandwidi passed by the ASEM 22 on behalf of the L1Q 20 or the VIP 12^ Med|um acce^ contrd 
a^owledgment messages and information are foiv^arded to the STTs 1 6 over Ethernet v.a the QAM mux/mod 52 and 

the QPSK mux/mod 58. ^ ^— <e u ,. -.\ o^r„i« 

The network controller 62 supports upstream access for interactive services requested from STTs 1 6 by. i ) admin- 
istering the adaptive MAC operation to maintain guaranteed minimal upstream latency and ensure fair "Psj^amacxess 
by all subscribed: and 2) forvvarding upstream data to the Li G 20. L2G. or addressable contrdter 24 v« the ATM sen^ 
ices mux 64. The network controller 62 also allows for the dynamic provisioning of multiple effective transmission rates 
according to the needs of the applications and services utilizing the network 10. 

The network controller 62 alleviates the L1G 20 from any functions pertaining to upstream access by overseeing 
network module 70. initialization (default carrier, default time division multiple access (TDMA) transmission time slote. 
etttls vSusl^^^^ dynamic TDMA carrier and time slot assignment whenever a ViP-VIU session is established. . 

thTprXS emb^iment. the network controller 62 is configured to accommodate n x (15 Mbps streams from 
a QPSK d«Tiod/mux 60 (1<n<S) and 1bn*raids the upstream ATM cells to an appropriate external routing/switching ele- 

""^The network module 70 interfaces the STT 16 to the hybrid fiber coaxial (HFC) physical medium 56. The network 
module 70 facilitates the extraction of RF signals and demodulating (64QAM or QPSK) these signals. Fon«ard error cor- 
^Son i^th^ performed before any data link layer (DLL) processing takes place. As part of the DLL process.ng the 
netork mo^le 70 may decrypt ceAain IBTM or OBTM components and perform AAL5-SDU based (upper layer) ^g^ 
S extraction. It forwards AAL5-SDU protocol data units (PDU) to the STT central processing unit as well as the 
service stream to the other STT processing elements. .. ^ ^^„ii„„«,«n™»h«, «5TTifi tn 

The neiwork module 70 under the management of the network controller 62 fonwards signaling from the STT 1 6 to 
the c^r^p^ng^eiork controller 62 whi?h forwards this information to the L1G 20 or to VIP 12 throug^^^^^ 
headend l^ckbone subnetwork 66 and the hub backbone subnetwork 40. The network module 70 also communicates 
with the addressable controller 24 for access control and decryption/encryption authorizaton. 

The QPSK demod/mux 60 receives up to six upstream carriers, demodulates the carriers and perforn^ forward 
40 error correction The resulting ATM cell streams are multiplexed to form a nominal 1 .5 Mbps stream which .s fon/.arded 
to Se ne^k controller 62. ^itionally. the QPSK demod/mux 60 fon.,ards measured values of certain phys.«l layer 
parameters to the network controller 62 for network module 70 power calibration, and p^rms "Pf ^L^^/y"^^™""^ 
Son supporting functions to facilitate ranging of STTs 1 6 (propagation delay calibration) for optimal ^DMA operaton. 
Th^mjx)nents shown in Rgure 3 which have not been accompanied herein by a specific description operate as 

45 the equivalent components shown in Figure 2. «, ,„,^inr. nf 

Although the aforementioned description of the specific components provides an understand ng of the 
each com^nent. a thorough understanding of the network architecture of the present inventon w.ll be further facilitated 
by a description of the signaling and communications between network components. . , . ..^ 

The inLmation from a VIP 12 to a STT 16 flows on an IBTM which is modulated as a 64QAM signal. whHe 'nfor- 

50 mation from the L-lG 20 to a STT 16 flows through either an IBTM or an OBTM. modulated as a QPSK s.gnal A down- 
stream path consists of both an IBTM and an OBTM destined to a STT 1 6. An "Ps«^«.^'^^^'9"f P^*^<=°"!;f 
16 to LI G 20 VIP 12 addressable controller 24. or network controller 62 signaling, via the network module 70, through 
the network controller 62. through the backbone subnetwork 40. In addition, an upstream path consists of signaling 
between the network module 70 and the network controller 62. All upstream signals are QPSK . _^ _ . 

55 With respect to the downstream path IBTM. the CATV communication network 1 0 uses the backbone s"bnetwo k 
40 to interconnect the VIP 12 to the ITEMs 30. 50. Digital streams containing compressed video material embedded in 
1?M ielfsTSfat the VIP 12. AAL5 adaptation is used to transport a MPEG2 ^^J^^' "^-"^^"^^'^^^^^^^^^ 
aling originating from the VIP 12 to the STT 16 is carried as IP/ATM (or any protocol/ATM) using AAL5 adaptation as 
well ?he ITEMS 30. 50 accept a plurality of the ATM streams, as instructed by the ASEM 22. to create an aggregate 
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MPTM whose aggregate nominal rate is 27Mbps. The V.P 12 inforn^the LIG f^^J^ll^^^'^"^;^^^^^ 
Required in support ^a given SPTM. The L1 G 20 in turn forwards this ''^<'''^»'°;;^^*^f^iiEM 22^^ 

which S^e ITEMS 30 50 present within a given headend 18 can accommodate the fP^-.T^e^AJEM ^ tnen 
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STT-L1Q signaling. demod/mux 60 which, in addition to demodulating a given 

P^Tliem »£„n «e con.*, 62 "^^^nZi »%eC.eSte h«d««. .8 and STTs 

cal input 90 is converted Into an electncal signal 7° and branch aspect of the 
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Table 1 provides the I/O interfaces of each component in the preferred embodiment. 

TABLE 1 



e 


CXDMPONENT 


INTERFACES 1 


W 


Addressable Controller 


I/O: 

- 2/lOBaseT Ethernet 

- 32 X RS-232 (4 x multipin- 
connector driving 8 port concentrator) 




Network Controller (NC 1000) 


Input : 

- 5 X EIA/RS-485 DTE I/F 


15 




Outputs : 

- 1 X ATM/DS3 (information rate 
<=9 Mbps) 


20 




I/O: 

- 2 X Ethernet lOBaseT 


25 


RF Modules Data Interfaces 


64QAM MUX/MOD 

- Input: 1 X TAXI ® 27Mbps 
riiif-t-iiit-« 1 V TF ® 43 75 MHZ 

(75 Ohm F-Connector) 

- I/O: 2 X Ethernet lOBaseT 


30 




QPSK MUX/MOD: 

- Input: 1 X EIA/RS-530 ® 

- Output: 1 X RF, Range: 71-12 9 

MHZ (75 Ohm F- 
Connector) 

- I/O: 2 X Ethernet lOBaseT 


35 




QPSK DEMOD/MUX: 

- Input : Upto 6 RF Inputs 

- Output: 1 X EIA/RS-485 ©1.5 

Mbps 

- I/O: 2 X Ethernet lOBase T 


40 


Integrated Transport 
Encryption Mux (ITEM 1000) 
Data Interfaces 


Input : 

- 1 X Optical Carrier 3- 
Concatenated (OC-3c, 155.52 
Mbps) 


45 




Outputs: 

- 5 X TAXI ® 27 Mbps 

- 1 X RS-530 ® 1.544 Mbps 


50 




I/O: 

- 1 X Ethernet lOBase T 

- 1 X RS-232 ® 19.2 Kbps 




Networlc Module Interfaces 


Input: 

- RF via F Connector 



55 
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COMPONENT 


INTERFACES 




Output : 

- RF Bypass via F Connector 
Video via RCA phono plug 
Audio Right and Left Channels 
via RCA phono plug 




I/O: 

Digital bidirectional 
interface, (32-pin molex 
connector) 



20 



30 



35 



Referring to Figure 5 a SST 16 is shown. Communications in the downstream path originating at the headend 18 
are transmitted through the coaxial drop line 96. Video information signals are processed through a frequency agile 
tuner 1 10 and a descramWer timing and control module (optional - if analog video is scrambled) 112 before entenng a 
television set 114. The tuner 110 is responsive to the frequency of the downstream channel selected by the V U to 
remove the carrier signal. The descrambler 112 deswamWes the baseband signal of the selected channel rf the VIU is 
an authorized user. Similarly, digital video passes through the decryption and then MPEG2 decodes and D/A conver- 
sion to fonward the composite video fbr display. (The baseband video signal is placed on a second earner signal fre- 
quency, typically television channel 3 or 4. fbr input into the television 114). The tuner 110 and «l^ramWw 112 are 
confrdled by the network module 70. which includes an encryption/decryption controller 124 and a MAC maaule 126. 

The network module 70 interfaces with a processor 116 which comprises a central processing unit (CPU) 118. a 
read only memory (ROM) 120 and a non-volatile random access memory (RAM) 122. Several processing components 
reside in the RAM 22. including an existing protocol syntax processor 128 (PSP). an adaPtive prot««l processor 130 
APP) a memory manager 132 and a transmit queue 134. The remaining portion of the RAM 122 is available for 
precising highJ layers of the protocol and for general use. The APP 130. which includes a primitve PSP is also res- 
ident in ROM 120 for initial start-up and recovery operation. The CPU 118. in conjunction with the different processing 
components in RAM 122. allows the STT 16 to read incoming data frames, parse the frames by sequentially stripping 
off each nested layer, and perform the application embedded therein. „^ ^ ^ • ^ .„ « „u , e«.,-«nH ire- 

Data frames within the OBTM forwarded through the headend 18 to the STT 1 6 are received through a second fre- 
quency agile receiver 140. which is tuned to the particular control channel for receh/ing confrol "^e^^ages. In the pre- 
ferred embodiment, the transmitter 142 transmits communications upstream from the STT 1 6 to the network controller 

The STT 16 is controlled via the subscriber remote control 144. The remote control 144 has an infrar«i (IR) signal 
emitter 146 which sends IR control signals to the IR receiver 148 as is well known in the art. The received control sig- 
nals are then fonwarded to the processor 116. _ 

In the oreferred embodiment of the present invention, the network architecture facilitates the upgrading of STTs 16 
by perSg SrSe replacement of the'pSP 128 resident witWn the STT 16 with a new PSP 129 without interrupting 

operation of the network 1 0 or the STT 16. » ee-r i e 

Rgures 6-14 illustrate an adaptive protocol wherein a protocol syntax processor resident within a SST 1 6 may be 
remotely upgraded. This will be described in detail in what follows. ... ^ ^ ^ , ..en^„™ 

Rgire 6 illustrates the basic layered protocol model which is well known to skilled artsans. The fraoie 150 corn- 
prises a signal transmitted through the network 10 from a source node, such as the network controller 62. to a destina- 

?S f ra'me^Srs a^I^^^^^ in nested layers. The layered model of Rgure 6 closely conforms to the reference model 
for Open Systems Interconnection (OSI) developed by the International Standards Organization. Geneva Sw't^Mand^ 
SDecHically the ultimate "data to be fransferred" is in the application layer 152. The application layer 152 is nes ed 
S t?e presluatrn layer 154. The presentation layer 154 is nested within the session layer 156. which -s nested 
ZTn he frari^rt layer 158. and so on through the network layer 160 and the link layer 162. In genera each layer 
, Tn^Ses a Veader 64 (which precedes the application data 152) and a trailer 168 (which follows the application data 
sTHo^^er f^r any given lajer, the respective header may be minimal and the respective trailer ';«yi>« -^^^^^^^^ 

The source node e g VIP 12 LiG 20. AC 24. NC 62 assembles the frame message layers (3-7) 150 before trans- 
mission to the STT 1 6 (destination node). The destination node parses the frame 1 50 one layer at a ^-^e^^^'^j jl^^: 
tinSon node sfrips the link layer 162 from the frame. The "data" of the link layer 1 62 is the network layer 160. The data 
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of the network layer 160 is the transport layer 158. and so on down to the application layer 152. Each layer of the pro- 
tocol is assigned specific system communication functions as briefly outlined below. 

The physical layer (not shown) is concerned with the electrical and mechanical characteristics associated with the 
physical network termination plug or socket. This includes the type of electrical signals used, the size and configuration 
of the connecting I/O plugs and the number and arrangement of pins. 

The link layer 162 provides the means to transfer data reliably over the medium. As detailed above, the link layer 
162 performs basic communication functions of medium access control when a shared medium is used, generation and 
checking of error detection codes, and source and destination node addressing within the network 10. The link layer 
162 for shared media is typically divided into two stto-layers: the MAC sub-layer and the logical link control (LLC) sub- 
layer. 

The network layer 160 specifies addressing and routing instructions to establish connections between the source 
and destination nodes located in different networks. The network layer 1 60 enables two networks to interconnect across 
one or more sub-networks, thereby providing a uniform end-to-end service to the transport layer. 

The transport layer 158 governs the data flow between the source and destination nodes once a signal path con- 
nection has been established. Typical functions of the transport layer 158 include data flow control, error control and 
message fragmentation. 

The session layer 156 provides the means for two communicating nodes to control their subsequent communica- 
tion. It also provides means to allow a communication to be restarted at a pre-determined synchronization point in the 
event of a communication failure. The session layer 156 comprises a set of functional units which must be established 
when the session connection is set up. 

the presentation layer 154 controls the format and syntax of data that is being exchanged between two communi- 
cating nodes. After a connection has been established, the presentation layer 154 allows the communicating nodes to 
establish a common syntax for the data to be exchanged. 

The application layer 154 includes the programs to be utilized by the subscriber. For example, in a video-on- 
demand application, the application layer 154 may contain specific instructions for L2G menu navigation and selection 
by authorized subscribers. 

Rgure 7 shows the prior art frame format 180 for the link layer protocol. A frame 180 includes a synchronization 
field 182 a protocol version fieW 184. a destination address field 186. a source address field 187. a control field 188. a 
link level message f ieW 1 90 and a cyclic redundancy code field (CRC) 1 91 . 

In contrast. Rgure 8 illustrates an ISO-OSI based layered protocol stack during protocol syntax processor upgrade. 
For clarity, only the heading of each layer is shown. The heading and the tail may include a full message, a nominal 
message or no message at all depending upon the frame to be sent. A given protocol stack may be comprised of any 
corr^ination of layers. Further, not alt layers need to be present in each protocol stack. The source node assembles the 
frame message starting with the application layer 192. The presentation layer 194 is then added, followed by the ses- 
sion layer 196. the transport layer 198 and the network layer 200. The protocol stack includes two data link layers: a 
new data link layer 202 which is nested within the old data link layer 204. 

Rgure 9 is an example of frame format of the link layer protocol 206. The frame 206 includes an eight bit synchro- 
nization field 208. an eight bit revision fieW 210. a twenty-four bit destination address fieW 212. a twenty-four bit source 
address field 21 3, an eight bit control field 21 4. an eight bit control subtype field 21 5. an eight bit length field 21 6. a link 
level message fieW 217 which may vary in length, and an eight bit CRC field 225. 

The protocol sent from the master node to the slave node contains instructions regarding the PSP 128 for the APR 
1 30 to follow. The control f ieW 214 within the link layer protocol 206 identifies the type and format of the inforn^tion to 
follow in the control subtype fiekJ 215. the length fieW 216. and the link level message field 217. The control field 214 
prompts the APP 130 to receive and process the frames within the protocol in a certain manner. As shown in Table 2, 
the APP 130 may be instructed to update the existing PSP 128. accept a completely new PSP 129. or perform other 
actions on the PSP 128. It shouW be evkJent to those skilled in the art that other control field types may be specified at 
a later date and included within a new or revised protocol syntax processor. DeperTding upon the type of control field 
214. additional fields may be necessary The number and length of additional fields are specified within the control sub- 
type 21 5 and length 21 6 fields, respectively. The additional fields are then transmitted within the link level message field 
21 7. The length field 21 6 indicates the length of the link level message 21 7 which, in essence, extends the length of the 
header. The length field 21 6 is indicative of how far the APP 1 30 must parse the frame in order to get to the new proto- 
col. In this manner the standard length of each field, the number of fields and the function of each field may be changed 
without physically replacing the node. 
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TABLE 2 





CTRL FIELD TYPE 


LENGTH RELD 


ADDITIONAL FIELDS 


0 


















Npw P<^P 


X 


sequence number image section 


3 


Last PSP 


X 


sequence number image section 


4 


Test New PSP 


X 


subtype, number of fields.... 


5 


Stand By 






6 


Activate PSP 






7 


Set New To Current 






8 


Use Current PSP 







The procedure for replacing a node's PSP 1 28 is shown in Rgure 1 0. Migration from the old PSP 1 28 to a new PSP 
129 is controlled by a "master" node which directs all "slave nodes". In the preferred embodiment, the master node is 
the network controller 62 and the slave nodes are the STTs 16. The master node initiates protocol migration by sending 
a migration initiation message to the APP 130 within the slave node, to prepare to receive a new PSP 129. 

The master node may initiate migration for all slave nodes, or may select spedfic slave nodes. The selection of 
slave nodes to be migrated to the new PSP may occur In several different ways. In the preferred embodiment, the mas- 
ter node polls all slave nodes to determine the type and revision of PSP 1 28 resident within each node. Each slave node 
provides the requested information in response to the master node. Alternatively, the master node may execute a rou- 
tine to interrogate each slave node to determine the type and revision of PSP 128 resident within each slave node. 
Depending upon the response, or lack thereof, from each slave node, the master node can determine which revision of 
PSP 128 is resident within each slave node. For example, if a slave node has an old PSP 128 revision, the slave node 
may be unable to respond to the query posed by the master node. Accordingly, the master node will determine that the 
PSP 128 resident within that slave node should be updated. 

Once the protocol migration process is initiated, the master node sends PSP image frames to the APP 130 within 
the link level message 217 portion of the link level frames 206 as shown in Rgure 9. As shown in step 230 of Rgure 
1 0. the APP 1 30 constructs, or loads, the new PSP image from the received frames 206 in RAM 122 that is not currently 
being used as directed by the memory manager 132. The memory manager 132 monitors and allocates usage of the 
RAM 1 22 by different processing components. 

After construction of the new PSP 129 image is complete, the master node directs the APP 130 to enter a verifica- 
tion phase of the new PSP 1 29 at step 232. The APP 1 30 processes special test frames sent to it that use the oW pro- 
tocol syntax to encapsulate information represented in the new protocol syntax. The verification is canied out on the 
frame portion that is utilizing the new protocol to ensure that the new PSP 129 is operating properly. The verification 
ensures that the new PSP 1 29 properly processes the frames. If the new PSP 1 29 fails, at step 236. the APP 1 30 sends 
a frame resend request and other en^or messages to the master node. 

The verification is performed utilizing the test frame structure shown in Rgure 11. The control field 214 and the 
control subtype fieW 215 identify the structure of the link level message field 217. For the verification phase, the control 
type will be 4/Test New PSP (as shown in Table 2). Table 3 displays the control subtypes associated with control type 
4/Test New PSR 



TABLE 3 



CONTROL SUBTYPE 


INFORMATION 


0 


Reserved 


1 


Image Checksum, image checksum value 


2 


Field Check, number of fields, f ieW length (bits), field value 
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There are two types of verifications as shown in Table 3; an image checksum and a field check. If the control type 
is 1/lmage Checksum, the APP 130 performs a checksum of the downloaded PSP image to ensure that it is equal to 
the indicated image checksum value. 

If the control subtype is 2/Field Check, the APP 130 performs a field check. As shown in Table 3. the control sub- 

5 type 21 5 indicates the number of fields, the length of each field and the value utilized to test the field. 

In order to test the fields, the values of each field are sent to the APP 130 along with the new protocol segment 
which is being tested. The APP 130 parses the new message and performs a calculation for comparison with the values 
indicated in the message. If they are not equal, an error message will be sent to the master node indicating that the 
slave node has failed the verification. 

10 Rgure 12 illustrates the procedure for testing the new PSP 129 in accordance with control type 4. At step 250, it is 
determined if an image checksum will be performed. If so. the image checksum is calculated at step 251 . and at step 
253 is compared to the image checksum value that has been transmitted. Depending upon the results of the compari- 
son, the PSP 129 will pass the test (step 256) or fail the test (step 255). Returning to step 250. if an image checksum 
is not to be performed, step 252 is entered to determine if a field check is to be performed. If not. the PSP 1 29 has failed 

75 the test (step 255). If a field check is to be performed, step 254 is entered and each field is checked to determine if the 
value of the field equals the values that have been transmitted. If any of the values are not equal, the PSP 1 29 has failed 
the test (step 255). If the values are equal, the PSP has passed the field check (step 256). 

Figure 13 is an example of values that could be transmitted in the test frame format in a field check. The frame 
begins with a sync number 208, a revision number 21 0. a destination address 21 2, a source address 21 3. and a control 

20 number 214. Since the control number is 4, the control type will be Test New PSP. The particular type of test is deter- 
mined by the control subtype 215 which is 2, indicating a field check. The length fieW 216 Indicates six fields to be 
checked. Each field indicates the length of the field and the value. Within the payload field 224 is included the new pro- 
tocol segment which has formatted values as if it were a new message. The following fields, included within the link level 
message 217 as shown in Rgure 9. will be checked: a four bit generic flow control (GFC) field 218. an eight bit virtual 

25 path identifier (VPl) field 21 9. a sixteen virtual channel identifier (VCl) field 220. a three bit payload type (PT) field 221 , 
a one bit cell loss priority (CLP) field 222. an eight bit header error check (HEC) f ieW 223. and a variable length payload 
fiekJ 224. 

The GFC field 218 is used to ensure fair and effident access between multiple devices sharing a medium. The VPl 
field 219 allows a group of virtual connections, called virtual paths, to be Identified. The VCl field 220 identifies the indi- 
30 vidual virtual connections within each virtual path. The PT field 221 is used to distinguish user information and network 
information. The CLP field 222 permits two priorities of cell to be defined where the network may discard low priority 
cells under congestion conditions. The value of the HEC field 223 is a function of the header (H). The HEC field 223 
provides an eight bit cyclic redundancy check on the contents of the cell header. A detailed description of the function 
of these f iekjs is outside the scope of this disclosure. (The definition of these fields is consistent with CCITT Recom- 

35 mendations 1.150 and 1.361 (Geneva. June 1992)). This is an example of the fieWs which are part of a new protocol 
which is encapsulated within the old protocol format. 

If the PSP 129 has failed the verification, the master node will note that an error has occurred and will restart the 
migration procedure. After a predetermined number of failed migration attempts, the master node will abort the migra- 
tion procedure and tag the particular slave node for servicing. Thereafter, all tagged slave nodes will be repaired or 

40 replaced. If the new PSP 129 passes the verification, the slave node is placed in a standby mode, as shown in Rgure 
10 at step 234. In this mode, the slave node is able to accept and process incoming frames with the new PSP 129 but 
is able to default to the oW PSP 1 28, The master node repeats the process with other slave nodes until all slave nodes 
of interest have gone through migration to the new PSP 129. 

Once the new PSP 129 has been installed on all of the slave nodes of interest, the transmission network 10 equip- 

45 ment upgrades associated with the new protocol, if any. may be performed. The master node then sends an activate 
frame using the new protocol format to all STT 1 6. In step 238. the slave nodes erase the old PSP 1 28 and execute the 
new PSP 129 thereafter This step may be delayed for a defined period of time after which no node failures occur due 
to the PSP 1 29 upgrade. The slave node then exits the PSP upgrade procedure. 

Although reference has been made to several different frame formats as examples of the operation of the adoptive 

so protocol, the preferred format is an MPEG2 compliant frame/packet format as shown in Figures 18 and 19. Referring 
to Rgure 18. the DLL packet sublayer frame 600 contains an eight bit sync field 601 . a one bit transport error indicator 
field 602. a one bit payload unit start indicator field 604. a one bit transport priority field 606. a thirteen bit packet iden- 
tifier field 608. a two bit transport scrambling control field 61 0. a two bit adaptation control field 612. a four bit continuity 
counter field 614. and an adaptation field 616 and payload field 618 comprising 188 bytes. 

55 The transport error indicator field 602 is a one bit flag that indicates that at least one uncorrectable bit error exists 
in the associated transport packet. The payload unit start indicator field 604 has a nominative meaning for transport 
packets that carry packetized elementary stream (PES) or program specific information (PSI) data as well as private 
data. A logical one indicates that the payload of this transport packet will commence with a pointer to the start of a mes- 
sage. The transport priority field 606 is a flag to indicate that the associated packet is of greater priority than packets 
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within the same PID stream that do not have the flag. The packet identifier field 608 indicates the type of data stored in 
the packet payload. The transport scrambling control field 610 indicates whether or not the paytoad is scrambled 
(erKrypted). The adaptation field control field 61 2 indicates whether the transport packet header is followed by an adap- 
tation fieW and/or a payload. The continuity counter field 614 is an incremental counter which increments with each 

5 transport packet with the same PID. The preferred embodimerrt of the present invention does not use the adaptation 
fiekJ 616 for nonaudio or video elementary streams. 

The message sublayer frame 619 of Rgure 19 is segmented and transported within the payload field 618 of DLL 
packet sublayer frame 600. The frame includes an eight bit message type field 620. a one bit reserved field 622. a three 
bit address type field 624. a twelve bit message length field 626. a forty, sixteen, or twenty-four bit address field 628. an 

TO eight bit protocol version field 630, an n-bit application (user layer) data field 632. and a thirty-two bit CRC (cyclic redun- 
dancy code) field 634. 

The message type field 620 is an eight bit field that distinguishes the type of application and the associated appli- 
cation layer message structure. The MPEG2 table format field 622 is a one bit flag that indicates if the message struc- 
ture conforms to those previously defined. The address type field 624, is defined as: 

15 

0 = Broadcast 

1 = Singlecast type 1 :40 bit physical address 

2 = Singlecast type 2:40 bit logical address 

3 = Multicast type 1 :40 bit address 
20 4 = Multicast type 2:1 6 bit address 

5 = Multicast type 3:24 bit address 

The protocol version f lekJ 630 indicates the version of the application message syntax. If the protocol-version number 
is recognized, the message/frame may be processed, otherwise it is discarded. The message body field 632 may con- 

25 sist of up to 1024 bytes of application layer protocol. The CRC field 634 provides a means of error detection. 

During the migration of the STTs 16 to the new PSP 129. a slave node may "crash" or lose communication with the 
master node. Accordingly, a recovery procedure is provided for reestablishing communication with the master node. 
The recovery procedure is facilitated by two features: 1) a universal subframe. and 2) a primitive PSP. The master node 
uses a universal subframe whenever the absence of a previously resident slave node is detected. The absence of a 

30 slave node is detected when the master node receives no response to instructions sent to a slave node. The universal 
subframe comprises a predefined bit pattern recognizable to the slave node when the slave node is attempting recov- 
ery. A primitive PSP that recognizes the universal subframe is included within the APP 130. 

The universal subframe and the primitive PSP enable downloading of the current PSP. in accordance with the pro- 
cedure previously described, even when the STT 16 is operating in a degraded condition (i.e. is operating with no other 

35 PSP than the primitive PSP). The new PSP Image data is appended to the universal subframe to enable the primitive 
PSP to recognize the frame and deliver the image information to the APP 1 30 for the construction of the new PSP. After 
recovery, the slave rxxle has the most current PSP being used by the STTs 16. 

The recovery procedure is shown in Rgure 14. As the slave node enters the recovery mode, it detects the universal 
subframe at step 240. and sends the master node a verification message that the subframe has been detected. The 

40 APP 1 30 utilizes the data appended on to the universal subframe to buiM the new PSP image in the RAM 122 at step 
242. After construction of the new PSP 129 is complete, the slave node executes the new PSP at step 244 and exits 
the recovery mode. 

The operation of the adaptive protocol scheme may be best described by using a state transition table representee 
tion as shown below. The scheme comprises the following four states: 1) current state, 2) input event. 3) next state, and 
45 4) output event. The cun-ent state is a state that the APP 1 30 is in prior to receiving an input event. An input event is a 
message from the master node which causes the APP 130 to perform certain actions and proceed to the next state. 
The next state corresponds to actions taken by the slave node and the following state transition. The output event cor- 
responds to the message generated from the slave node to the master node. 

50 
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TABLE 4 



10 



15 



20 



25 



30 



Current State 



Use - Current - PSP 



Prepare- f or- 
New-PSP 



Prepare- f or- 
New-PSP 
(cont . ) 



Build-New-PSP- 
Image 



Input Bvent 



Expected event 

Rx-Update-PSP 



Unexpected events 
Rx - New - PS P - Frame 
Rx- Las t - PSP - Frame 
Rx-Test -New- PSP- Frame 
Rx- S tandby - Frame 
Rx-Activate-New-PSP 
Rx- Set -New -To -Current 
Rx-Use-Curr-PSP 



Expected event 
Rx-Update-PSP 



Expected event 
Rx-New- PSP- Frame 



Unexpected events 
Rx-Update-PSP 
Rx- Las t - PS P - Frame 
Rx - Tes t - New - PS P - F r ame 
Rx- Standby- Frame 



Rx-Activate-New-PSP 
Rx- Set -New -To -Current 

Rx-Use-Curr-PSP 



Expected event 
Rx-New- PSP- Frame 



Expected event 
Rx- Last -PSP -Frame 



Next 
Action/State 



Prepare for 
New- PSP 



Use - Current -PSP 



Output 
Bvent 



Tx- Event -Out -of - 
Sync (event, curr- 
state) 



Prepare- for- 
New-PSP 



Build-New-PSP- 
Image 



Act 01: Abort & 
Cleanup, Use - 
Current -PSP 



Build-New- PSP- 
Image 



Test-New-PSP 



Tx-Event-Out-of - 
Sync ( event , cur r - 
state) 



35 



40 



unexpected event 
Rx-Update-PSP 
Rx-Test -New- PSP- Frame 
Rx- Standby -Frame 
Rx-Activate-New-PSP 
Rx-Set-New-To- Current 



Act 01: Abort & 
Cleanup 

Build-New-PSP- 
Image 



Tx- Event -Out -of - 
Sync (event, curr- 
state) 



unexpected event 
Detect -out -of -Sync- 
Frame* 



Build-New-PSP- 
Image 



Tx - Frame - Out - of - 
Sync (f rame- 
sequence - no) 



45 
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Current 


State 


Input Rvent 


Next 
Action/State 


=^^^=^ 

W/Uwpuu 

Event 


5 






Unexpected event 
Rx-Use-Curr-?SP 


Act 01: Abort 
Cleanup, Use- 
Current-PSP 


& 


Tx - Even t - Out -of- 
State) 


10 


Test -New 


-PSP 


Rx - Tes t - New - PSP - Frame 


Test-New-PSP 


jir uesu resuic 
< > unsuccessful, 
TX-test-Failure 
(failure code) 








Expected event 
Rx - S tandby - Frame 


Standby 




IS 






Rx-Tes t - New - PSP - Frame 

Rx - Las t - PSP - Frame 

Rx-Update-PSP 

Rx - New- PSP - Frame 

Rx - Se t - New - To - Current 


Test-New-PSP 


Tx - Event - Out - of - 
Sync { event , curr- 
state) 


20 




imexpected event 

KX- use- wurr * rslr 


Act 01: Abort 
Cleanup, Use- 
Cur rent -PSP 


& 


ix- avenc-wut-ot - 
Sync ( event , curr- 
state) 


25 


Standby 




Expected event 
Rx - Standby - Frame 


Stamdby 










Expected event 
Rx - Act i va te - Ne w - PS P 


Use-New- PSP 




30 


Standby 
(cont . ) 




Expected event 
Rx- Test -New -PSP -Frame 
Rx - Las t - PSP - Frame 
Rx- Update -PSP- Frame 
Rx-New- PSP - Frame 
Rx- Set -New- To - Current 


Standby 


Tx - Event - Out - of - 
Sync ( event , cur r - 
Suace/ 


35 






Oaexpected event 
Rx-Use-Curr- PSP 


Act 01: Abort 
Cleanup, Use- 
Current- PSP 


& 


Tx-Event-Out-of - 
oyncvevenc, curr- 
state) 


40 


Use -New- 


PSP 


Expected event 
Rx- Set -New- To - Current 


Act 02: Final - 
Cleanup 

Use - Current - PSP 




45 






Rx-Update-PSP 
Rx - New- PS P - Frame 
Rx-Last-PSP-F r ame 
Rx-Test-New-PSP 
Rx -Standby- Frame 
Rx-Activate-New- PSP 


Use -New- PSP 


Tx- Event -Out - of - 
Sync ( event , cur r - 

e t* a t* A \ 


50 






Unexpected event 
Rx-Use-Curr-PSP 


Act 01: Abort & 
Cleanup 

Use -Current -PSP 


Tx - Event -Out - of - 
Sync (event, curr- 
state) II 



55 

Each transition to or from the states in Table 4 has a set of actions associated with it. A transition to a more 
advanced state is conditional upon getting an expected outcome from the response of each current state to the input 
event. If an expected state is not achieved, the APP 1 30 will remain in the current state or revert to a previous state. 
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The adaptive protocol scheme described herein not only permits upgrading of STTs. but also adaptation of STTs 
16 belonging to one network to another new network, where the latter uses a different communication network infra- 
structure. This eliminates the need for maintaining two or more separate networks and enables all systems to migrate 
to the latest system, provided the STT 16 hardware does not require any changes. This approach eliminates the back- 
ward capability limitations imposed by fixed protocols by enabling the migration of existing systems to new protocols to 
take advantage of new. more enabling protocols in a cost effective manner. 

The preferred embodiment of the network architecture also employs a hybrid medium access control (MAC) system 
400 to control access to the upstream bandwidth by the plurality of STTs 16. The hybrid MAC system 400 comprises 
different MAC components which are selected based upon the type of communication that is associated with the corre- 
sponding application or service selected by the VIU. Each MAC component resides on a separate frequency. MAC 
parameters are configurable to provide additional flexibility and operational and resource optimization (such as latency, 
probability of blocking and bandwidth utilization). 

Applications and services selected by the VIU can be categorized according to the communications required to 
support the application or service. The first category of applications and services are associated with asynchronous, 
latency independent communications. These communications are the least demanding from a performance standpoint 
since the applications and services are capable of functioning effectively with response time latencies of minutes or 
hours. This is typical of transactions that do not require a subsequent action to be performed by the application or the 
network 10 in support of a VIU visible response to an original action. For these applications and services, the time that 
it takes to deliver the data to the associated destination is not a critical factor. 

The second category of applications and services are associated with asynchronous, contention-prone communi- 
cations. These communications place medium demands on performance and thus, maximum response latencies on 
the order of sub-seconds are required. This category includes transactions and services that are followed by a subse- 
quent action at the application, the LIG 20. or the VIP 12 in support of a VIU visible response to an original action. 
Timely delivery of information on the order of microseconds is critical for applications such as information on demand 
and video-on-demand applications: 

The third category of applications are associated with isosynchronous communications. These are the most 
demanding in terms of bandwidth, guaranteed maximum latencies (milliseconds), and a symmetric utilization of 
upstream and downstream bandwidths. Advanced multi-media applications, plain oW telephony service (POTS), per- 
sonal communication services (PCS), and video telephony are some of the applications in this category. By allocating 
a separate portion of the bandwidth for different types of communications, the hybrid MAC system 400 of the present 
invention will support future services that are not yet envisioned. 

Referring to Figure 16. the configurable hybrid MAC system 400 employs space division multiplexing, frequency 
division multiplexing, and time division multiplexing to efficiently utilize the upstream bandwidth. The space domain 
allows for dividing the subscriber population into smaller segments based on a number of factors such as physical loca- 
tion, subscriber population density and projected growth. Each network controller 62 may be assigned a number of 
physical signal transmission paths, such as a fiber 90 and associated carriers. This allows for gradual network expan- 
sion from the physical topology standpoint since additional network controllers 62 may be added to the headend 18 
based upon the performance needs of the network which are a function of fiber to the node (FTTN) size, service take 
rate, or simultaneous usage of a given service, etc. 

The frequency domain fadlitates the efficient support of the hybrid MAC components as well as further segmenta- 
tion of the settop terminal 16 population. Each of the hybrid MAC components are allocated a portion of the upstream 
bandwidth having at least one RF carrier frequency. This is a primary factor behind the simplicity of the design tiiat 
could not be achieved by prior art MAC methods that attempted to support asynchronous, anisochronous and isoso- 
chronous data without distinct channel separation. 

The time domain is used to allow multiple access at tiie smallest granularity as compared to the other two domains. 
The time domain is the basis for the fixed and both types of dynamic TDMA MAC components, (dynamic multi-rate 
TDMA and random slot resen/ation-dynamic slot assignment (RSR-DSA) TDMA). Multiple access within the same STT 
16 population segment and tiie same allocated upstream frequency is achieved in this domain. 

The hybrid MAC system 400 is adjustable to the variety of current and future applications that may be added from 
a network resource support standpoint by categorizing each application (as aforementioned) according to the network 
resources required to support the following types of communications: 1) isochronous communications; and 2) asyn- 
chronous communications including, latency independent and contention-prone communications. 

In operation, the network controller 62 receives a plurality of service requests over preassigned default connections 
from the plurality of STTs 1 6. These requests are fonwarded to the network controller 62 tiirough the QPSK demod/mux 
60 Once allocation of resources (frequency and time domain) are selected by the network controller 62. confirmation 
is sent downstream to the MAC module 126 via OBTM through an appropriate QPSK mux/mod 58. The process is 
repeated by other STTs 16 as application and service session requests are made. 

Referring to Rgure 5. the prefen-ed STT 16 for implementing the hybrid MAC system 400 is shown. The STT 16 
includes a medium access control module 1 26 and a decryption/encryption control module 1 24 for communicating witii 
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the network controller 62 through the transmission network 56. The STT 16 initiates a service request when the VIU 
selects a particular application, sen/ice. or session. The MAC module 126 analyzes, based on well known application 
service types, the communication requirements (i.e. isosynchronous. asynchronous) of the requested service or ses- 
sion type and selects the MAC component which will most closely meet the communication requirements. Since each 
MAC component has a preassigned upstream bandwidth, the frequency agile data transmitter 142. at the direction of 
the MAC module 126. is tuned to a frequency allocated to the particular MAC component. The STT 16 thereafter com- 
municates over that frequency until the connection is released (communication terminates) and/or the network control- 
ler 62 reassigns or reallocates resources. 

Alternatively a network controller client, such as ASEM 22. may request (on behalf the LIG) the allocation of 
resources in support a session of a given service. Once the network controller 62. allocates the appropriate MAC 
resources, it informs the STT16 of the relevant MAC parameters associated with the connection established in support 

of the requested session. ■ u 

Referring to Rgure 15. a TDMA frame 410 as used by the dynamic multi-rate TDMA MAC component is shown. 
The frame 410 comprises a series of time slots 412 which may be separated by in time 414. The configurable parame- 
ters for the dynamic multi-rate MAC corrponent are the frame size, the time slot size and the spacing 414 between time 
slots 412 The size of the frame 410 may be varied by increasing or decreasing the number of time slots 412. This 
affects the latency and the effective transmission rate of the communication. The size of the time slot 412 may also be 
varied to change the number of clock cycles within a time slot, and therefore the number of packets, that may be trans- 
mitted in a given time slot 412 (again, changing the effective transmission rate). The spacing 414 between time slots 
412 may be varied to change the number of packets which may be transmitted within a given frame 410. The adjust- 
ment of the spacing 414 between time slots 412 is also used for propagation delays to compensate for the different 
physical distances of the STTs 1 6 from the network controller 62. 

The static TDMA MAC component is typically assigned by the network controller 62 based on a connect request 
from a network controller client such as ASEM 22. For the static TDMA MAC component, the TDMA frame is fixed at 
one time slot per STT 16. This provides guaranteed bandwidth for access by STTs 16 within a given frame time con- 
veying additional connection requests or conveying diagnostic/status informatipn which may also be fonnrarded on the 

''^''imh^ preferred embodiment, the RSR-OSA MAC component is the default TDMA channel for large nodes with high 
take rates in place of the static TDMA. If the MAC module 126 has determined that the requested service is suited for 
random slot reservation - dynamic slot allocation (RSR-DSA). the STT 16 initiates upstream communicat tons by ran- 
domly selecting a time slot 412 within a given frame 410 or by transmitting on a previously reserved time slot 412 The • 
probability of collisions is inversely proportional to the number of time slots 412 per frame 41 0 and directly pro^rtiona^ 
to the number of STTs 1 6 that need to communicate during that cycle. The network controller 62 assigns the RSR-DSA 
TDMA frames 410 in accordance with the procedure shown in Rgure 17A. In step 300 the STT16 may reserve a time 
slot 412 once, or may request reserving the time slot 412 over multiple cycles. This reservation request is transmitted 
upstream over a randomly selected time slot 412 (step 302). If a collision is detected by the network controller 62^he 
network controller 62 transmitsamessage to the STTsieto retransmit the request (step 303). " "° 
by the network controller 62. the network controller 62 receives the request (step 304) and sends an acknowledgmer^t 
to the requesting settop terminal 16 and to all other STTs 16 that the particular slot within that channel is no longer avail- 
able (step 306) The STT 16 receives this acknowledgment (step 308) and the requesting STT 16 beings communica- 
ttons The network controller 62 dynamically assigns the requested time slot 412 by acknowledging af^^f^^tion by a 
message sent to the STT 16 in the downstream OBTM. The same acknowledgment indicates to other STTs 1 6 mat the 
time slot 412 is no longer available. After the STT 16 has terminated communications (step 310). tJ-^e slo 412 is 
released. The network controller 62 monitors the channel activity (step 312). and when it determmes (s^ep 314) that the 
timTsS 412 has been released, a "time slot free" message is sent to all STT 16 (step 316^ A STTs 16 rece-ve an 
acknowledgment that the time slot 412 is available (step 318). If. while monitoring channel activity (step 412). the net- 
woTk^Sr 62 determines that there is too much activity over a particular channel (step 320). the "^Nvork controHer 
62 adjusts the number of time slots 412. and increases the size of the frame 410, adjusts the spacing 414 between tme 
slots 412 or allocates additional frequencies (step 322). If the increased frame size is greater ^^^'^ ^'^l^^'l^^'^l 
fixed TDMA frame size, (stem 324) the network controller 62 determines that particular channel is to be designated a 

^*^*'wSe theS^-'S?d?sato the connectionless mode of operation intended for the default TDMA channel in a 
large node size and high-take rate, the connection-oriented mode is similar in the sense that a time ^'ot 41 2 or set of 
time slots may be resen/ed over multiple cycles (frames) for the duration of the connection. Additional information may 
be conveyed by the network controller 62 during connection establishment and connection release phases. 

in the connection-oriented mode, where multi-rate dynamic TDMA is used, the network controller 62 may assign a 
frequency and a time slot(s) for the duration of the connection, (typical of applicattons benef rting from guaranteed band- 
wSh h'nce^rLictable iLtUy.n support of interactK^e applications). Referring to ^'^-e 17B .nthis m^^^^^ 
controller client (e.g. ASEM 22). or a network module 70 client (e.g. an application within the STT 16) fon«ards a con 
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nection request (step 700) to the network controller 62 specifying which STT 16 is to be connected and the associated 
TDMA rate desired for that connection. (480 iDps. ... 2400 bps ... 32 bps ... 142k, 1 1520. 16000. 19200. 15360. 32000. 
56000. 64000. 1 12000. 128000. 192000 bps). This rate is a function of the level of interactivity which is characteristic 
of the application. For isosynchronous services (video, telephony or POTs). the rates depend on the service itself (e.g. 

5 video, telephony using 64 kbps or 128 kbps). 

The network controller 62 checks the available resources (step 702) to determine if the new request can be accom- 
modated. If required resources (e.g. number of time slots 412) are not available (on any of the frequencies supporting 
the requested rate or lower multiples of that rate), the network controller 62 rejects the connection request specifying 
the reason (e.g. no available resources). If on the other hand the network controller 62 determines that the required 

10 resources are available (step 704) it reserves the selected time slots 412 within the appropriate frequency (step 708). 
informs the network module of such parameters, and returns to the client a confirmation to the connection request (step 
710). 

When the connect request is originated by ASEM 22. the request is forwarded on the network controller's 62 Ether- 
net port When the request is fon^varded by the STT 16. the network module 70 may fon/vard the request on the defined 

j5 static TDMA channel or the RSR-DSA default TDMA channel (whichever is employed at the time within a given system). 
The plain old polling component of the MAC system 400 is intended for applications that benefit from a store and 
fonward system where collisions are expected but the latency associated with POP response is irrelevant. Additionally, 
it facilitates controlled communications for any diagnostic operation and presents a fall back communication method for 
diagnostic purposes should other conrponents of the hybrid MAC system 400 fail. 

20 If the MAC module 126 determines that POP is required, the data transmitter 142 is tuned to the POP frequency 
and a service message is placed in the polling queue 204. 

The polling service may be initiated periodically by the network controller 62 to instruct the STT 16 to purge their 
polling queue, or a polling request may be transmitted by the STT 16, The polling queue 134 operates as a first-in-first- 
out (FIFO) buffer which resides in the settop RAM 122. When an application or service requires to send a message 

25 upstream, the information is fonwarded utilizing resources assigned to the connection supporting the application ses- 
sion. If the information is in response to a poll, the message is copied into the polling queue 134. 

The STT 16 transmits the FIFO entries when it receives the polling token, which is an instruction by the network 
controller 62 for the STT 16 to empty its transmit queue 204. The polling token is broadcast on ail OBTM downstream 
channels and the STT 16 transmits on the polling channel frequency When the network controller 62 cames out the 

30 polling cycle, it has no knowledge of the OBTM downstream frequency to which the STT 1 6 is tuned. This necessitates 
sending the polling token on all downstream OBTM carriers for a given neighborhood. Once a STT 16 gets the token, 
it is permitted to empty its entire polling queue 134. The objective is to minimize the nunt^er of individual polling cycles 
required to empty the STTs entire queue 134. The network controller 62 then reads the messages from the plurality of 

STTS16. . . 

35 The hybrid MAC of the present invention supports of isochronous and anisochronous multi-media communications 
data in a cost effective and efficient manner In addition, connection-orientated as well as connectionless services have 
been supported, where the former requires a guaranteed bandwidth allotment over the duration of the connection. 

Although the invention has been described in part by making detailed reference to certain specific embodiments, 
such details is intended to be instructive rather than restrictive. It will be appreciated by those skilled in the art that many 

40 variations may be made in the structure and mode of operation without departing from the spirit and scope of the inven- 
tion as disclosed in the teachings herein. 

Claims 

45 1 , A communication system network comprising : 
a remote hub; 

a plurality of head ends associated with said remote hub via a fiber optic interface; 

a plurality of user terminals associated with each head end via a hybrid fiber coax interface; 

50 said remote hub comprising: 

means for communicating with interactive and broadcast video information providers (VIPs); 
means for formatting broadcast signals received from selected VIPs of the broadcast VIPs for direct transmis- 
sion to the head end/user terminal interfaces such that the user terminals receive said formatted broadcast sig- 
nals without reformatting by said headends; 

55 means for selectively controlling distribution of communication signals between said interactive VIPs and said 

headends; and 

means for tracking usage of VIP services by said user terminals for at least billing purposes; and 

each said headend including means for facilitating interactive VIP communications between its associated user 

terminals and said VIPs. 
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The system of claim 1 . wherein communications over said headend/user terminal interfaces are at least frequency 
multiplexed into a plurality of downstream channels from said headends and upstream channels to said headends 
such that the number of downstream channels Is substantially greater than the number of upstream channels. 

The system of claim 2 wherein said upstream channels are paired with selected downstream channels and com- 
munications on at least selected channel pairs are time division multiplexed. 
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FIG. 4 
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FIG. 12 
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FIG.17A 
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FIG.17A-1 
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FIG.17B 
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